\section{Piano di qualit\`a}
Per evitare di individuare in ritardo eventuali errori commessi nella fase di progettazione e di implementazione, fatto che causerebbe un notevole aumento di costi di produzione per quello che riguarda tempi e risorse impiegate per la produzione del software richiesto, sono stati effettuati svariati test in tempi e con modalit\`a diversi. Ad ogni passo in avanti nella produzione del software, sono stati eseguiti tutti i test possibili gi\`a eseguiti in precedenza e ne sono stati effettuati altri per poter testare le funzionalit\`a introdotte. In questo modo, partendo da una base stabile, ogni volta che si \`e aggiunta una nuova funzionalit\`a, anche parziale, sono stati eseguiti test sia sulla singola funzionalit\`a per testarne la correttezza, sia sull'intero prodotto disponibile nella fase in questione, in modo da poter testare anche l'interazione della nuova funzionalit\`a con le altre ed individuare e correggere eventuali errori provocati dall'aggiunta effettuata.

Cos\`i facendo, procedendo a piccoli passi, gli errori commessi sono stati individuati molto rapidamente e molto pi\`u facilmente. Inoltre, diminuendo la complessit\`a e la gravit\`a degli errori, le relative correzioni risultano anch'esse pi\`u semplici e soprattutto comportano modifiche a porzioni limitate di codice.

 
%qualit\`a codice??? tipo pattern, riutilizzo codice, sviluppi futuri applicabili facilmente ??????? OpenUP????

\section{Testing}
Durante la fase di sviluppo del prodotto sono stati effettuati i seguenti tipi di test, eseguiti in tempi diversi.

\subsection{Test use case}
Come riportato in precedenza, la fase di stesura degli use case \`e stata effettuata in pi\`u iterazioni. In questo modo, alla fine di ogni iterazione, tutti i componenti del gruppo assieme e singolarmente hanno analizzato il risultato prodotto e discusso eventuali mancanze e modifiche, in modo da ottenere un prodotto stabile su cui fosse possibile, nelle successive iterazione, aggiungere nuove funzionalit\`a e quindi nuovi casi d'uso, senza dover modificare ci\`o che era stato fatto nelle iterazioni precedenti.

\subsection{Test automatico all'interno del container}
Nella fase di implementazione, ad ogni funzionalit\`a sviluppata \`e stato effettuato come prima cosa un test eseguito direttamente all'interno del container di JBoss. In questo modo \`e stato possibile testare il funzionamento interno delle varie bean, lasciando ai test successivi l'analisi dell'iterazione tra l'interfaccia utente (i JSP) e le bean. Questo tipo di test \`e stato effettuato all'interno del container in modo da poter accedere a tutti gli strumenti e le risorse messe a disposizione da JBoss, quali per esempio l'Entity Manager. Oltre a verificare il corretto funzionamento del sistema al suo interno, questo tipo di test ha permesso di inserire in modo automatizzato alcuni libri, dei clienti gi\`a registrati, degli amministratori e degli ordini, elementi del sistema utilizzabili in questo modo anche dai successivi test eseguiti all'esterno del container, tramite browser, effettuati per analizzare l'interazione tra l'interfaccia utente e il sistema. 

Le varie funzionalit\`a di cui \`e stato effettuato il test all'interno del container sono riportate qui di seguito, mantenendo l'ordine cronologico con cui sono stati eseguiti i test.


\subsubsection{Registrazione}
La prima funzionalit\`a implementata e quindi testata \`e stata la registrazione da parte di un cliente nel sistema. La routine di test crea due clienti e ne esegue la registrazione inserendo tutti in campi richiesti in modo corretto. Inoltre viene anche eseguito un controllo sulla gestione dell'errore, eseguito facendo tentativi errati di registrazione di un cliente, per esempio non inserendo uno dei campi obbligatori, oppure immettendo campi con un formato chiaramente errato (la mail ha un formato specifico, alcuni campi come il cognome, il nome ... ammettono solo caratteri appartenenti all'alfabeto).

Clienti creati e registrati correttamente:
\begin{itemize}
 \item cliente1:
 \begin{itemize}
  \item password = "as23"
  \item name = "Mario"
  \item surname = "Rossi"
  \item email = "mario23@gmail.com" 
  \item address = "piazza verdi" 
  \item city = "Bologna"
  \item state = "Italia"
  \item telephone = "80978665"
  \item cap = "1234"
 \end{itemize}
 \item cliente2:
 \begin{itemize}
  \item password = "abc"
  \item name = "Giulio"
  \item surname = "Grassi"
  \item email = "giulio@hotmail.com" 
  \item address = "via Papa clemente XIV" 
  \item city = "Sant'angelo in Vado"
  \item state = "Italia"
  \item telephone = "13286639"
  \item cap = "61048"
 \end{itemize}
\end{itemize}

\subsubsection{Creazione amministratori}
Vengono forniti nel sistema anche strumenti per la creazione di amministratori, non accessibili per\`o tramite web. In questa fase il test ha controllato la corretta creazione dell'amministratore, verifica effettuata anche manualmente analizzando il contenuto del database del sistema, in particolare della tabella ProfileUser, da cui \`e possibile ottenere informazioni riguardanti tutte le persone registrate nel sistema, siano esse clienti o amministratori. La distinzione tra le due categorie \`e resa possibile dalla presenza di un campo apposito dei record della tabella, in cui viene appunto specificato se la persona registrata \`e un cliente oppure un'amministratore.
\begin{itemize}
 \item password = "ac!a"
 \item name = "giovanni"
 \item surname = "rossi"
 \item email = "giovanni.rossi@gmail.com"
 \item username = "giova" 
\end{itemize}

\subsubsection{Autenticazione}
Dopo aver reso possibile la popolazione della tabella con tutte le persone registrate nel sistema (ProfileUser), \`e stata implementata la funzionalit\`a di autenticazione. La routine di test relativa effettua vari tentativi di login e di logout in questo modo:
\begin{itemize}
 \item login effettuati con username e password errati;
 \item login effettuati con username errati e password corretti;
 \item login effettuati con username corretti e password corretti;
 \item login con parametri corretti, ma di una persona gi\`a autenticata;
 \item logout di clienti autenticati;
 \item logout di clienti non autenticati: in realt\`a questa evenienza \`e possibile solo nel test eseguito all'interno del container, perch\`e un cliente acceder\`a al sistema tramite browser e saranno le stesse interfacce JSP a mostrare il servizio di logout solo a clienti gi\`a autenticati. Il test \`e stato effettuato comunque per evitare che un'eventuale errore nell'interfaccia crei problemi all'interno del sistema.
\end{itemize}

Le prove appena riportate sono state effettuate sia per i clienti che per l'amministratore.
 
\subsubsection{Inserimento libri nel catalogo}
La funzionalit\`a di inserimento libri nel catalogo prevede che un amministratore autenticato possa aggiungere dei nuovi libri al catalogo del negozio, specificando inoltre se il libro in questione vada messo anche in vetrina oppure no. Nella routine di test sono state effettuate le seguenti operazioni:
\begin{itemize}
 \item tentativo di creazione di un libro da parte di un cliente: a prodotto finito sar\`a la stessa interfaccia verso il cliente a non mostrargli questa opzione;
 \item tentativo di creazione di un libro da parte di un amministratore non autenticato;
 \item tentativo di creazione di un libro da parte di un amministratore autenticato, ma non inserendo tutti i dati sul libro;
 \item tentativo di creazione di un libro inserendo dati con corretti sintatticamente (per esempio lettere al posto del prezzo);
 \item creazione di un libro con tutti i dati inseriti correttamente
\end{itemize}

Alla fine del test nel negozio sono disponibili 4 libri; come esempio qui di seguito vengono riportati i dettagli di uno di questi:
\begin{itemize}
 \item Isbn: 1zxc54;
 \item Titolo: 1984;
 \item Autore: Orwell;
 \item Tipologia: romanzo;
 \item Tag: politico;
 \item Prezzo: 16;
 \item Anno: 1950
 \item Casa editrice: feltrinelli;
 \item vetrina: SI
\end{itemize}

\subsubsection{Ricerca libri}
La routine di test ha effettuato ricerche di libri variando i criteri scelti per la ricerca, i dati inseriti e le varie combinazioni tra i criteri scelti. Alcuni esempi di test effettuati vengono:
\begin{itemize}
 \item ricerche che non avrebbero fornito alcun risultato;
 \item ricerche vuote;
 \item ricerche scegliendo un solo criterio di selezione;
 \item ricerche scegliendo pi\`u criteri di selezione;
 \item ricerche con i dati testuali inseriti che avevano una corrispondenza nel database, con l'unica differenza nell'utilizzo di maiuscole e minuscole.
\end{itemize}

\subsubsection{Aggiunta libri nel carrello}
Implementata la funzionalit\`a carrello, il test relativo si \`e suddiviso in due parti:
\\ la prima verificava la corretta creazione e rimozione del carrello, che per scelta progettuale devono avvenire rispettivamente nel momento in cui un cliente si autentica ed esegue il logout. Per controllare ci\`o si \`e preso uno dei clienti creati al momento della registrazione e si sono eseguite le operazioni di login e logout e si \`e verificata la corretta creazione di un carrello (vuoto) e la sua distruzione. Si \`e inoltre verificato che un amministratore, una volta autenticato, non abbia un carrello associato.
\\ La seconda fase del test verifica invece la corretta aggiunta di libri in un carrello da parte del cliente associato ad esso. La routine effettua una ricerca dal catalogo ed esegue le seguenti operazioni:
\begin{itemize}
 \item inserisce vari libri nel carrello;
 \item effettua la rimozione di un libro presente nel carrello;
 \item effettua la rimozione di un libro non presente nel carrello; questa possibilit\`a viene comunque evitata dall'interfaccia JSP;
 \item effettua l'aggiunta nel carrello di un libro gi\`a presente
 \item aggiunta di un libro inesistente
\end{itemize}

In tutte le operazioni si \`e verificato il corretto aggiornamento del numero di copie disponibili dei libri nel database del negozio.

\subsubsection{Checkout carrello}
La routine in questione controlla la corretta creazione dell'ordine da parte di un cliente. In particolare sono state verificate:
\begin{itemize}
 \item creazione di un ordine relativo ad un carrello contenente almeno un libro;
 \item creazione di un ordine relativo ad un carrello vuoto;
 \item corretto calcolo del prezzo totale dell'ordine.
 \item Alle verifiche automatizzate si \`e aggiunta anche la verifica manuale fatta dall'esecutore del test, che ha controllato l'effettiva presenza dell'ordine
nel database e lo svuotamento del relativo carrello.
\end{itemize}

\subsubsection{Risposta dal Sistema di Pagamento}
In attesa della creazione del sistema di pagamento, il test sull'ordine simulava il sistema di pagamento fornendo direttamente al sistema l'esito del pagamento, in modo da poter verificare la corretta chiusura del ciclo di acquisto di un libro da parte del cliente senza introdurre il Sistema di Pagamento, il quale, a sua volta, poteva introdurre ulteriori errori. Solo una volta che si \`e appurato che il sistema, al suo interno, si comportava in modo corretto, \`e stato inserito il Sistema di Pagamento. Quest'ultimo pu\`o segnalare al sistema la seguente informazione: pagamento effettuato correttamente oppure no. In base alla risposta del Sistema di Pagamento, si sono verificati i seguenti eventi:
\begin{itemize}
 \item Pagamento effettuato correttamente:
 \begin{itemize}
  \item stato ordine Closed;
  \item procedure di consegna ordine avviate;
  \item aggiornamento numero copie presenti in magazzino dei libri ordinati
 \end{itemize}
 \item Pagamento non effettuato correttamente:
 \begin{itemize}
  \item ordine annullato;
  \item ripristino numero copie disponibile dei libri presenti nell'ordine;
  \item stato ordine Cancelled.
 \end{itemize}
\end{itemize}
  
\subsubsection{Risposta dal Sistema di Consegna}
Gli unici test effettuati in questa fase sono stati la verifica della corretta restituzione da parte del Sistema di Consegna del codice di consegna dell'ordine e la sua corretta visualizzazione nel profilo del cliente.

\subsubsection{Ordinamento risultati ricerca}
Una volta implementata questa funzione, il corrispondete test \`e stato inserito nella precedente routine di test di ricerca libri. L'aggiunta ha verificato il corretto ordinamento (ascendente, discendete o nullo) dei vari parametri di ricerca. Anche se si \`e deciso che l'interfaccia JSP permetta all'utente di scegliere un solo campo alla volta da ordinare, il test ha comunque eseguito anche ordinamenti composti, in modo da permettere in futuro l'accesso a questa funzionalit\`a ai clienti senza dover modificare l'implementazione del sistema, ad eccezione dell'interfaccia relativa.

\subsubsection{Modifica carrello}
Per semplicit\`a, questo test \`e stato aggiunto direttamente alla routine che verifica l'aggiunta libri nel carrello. La nuova routine di test, oltre ad effettuare le rimozioni e le aggiunte di libri descritte in precedenza, esegue le seguenti operazioni:
\begin{itemize}
 \item aggiunta di pi\`u copie di un libro presente nel carrello;
 \item rimozione di alcune copie di un libro presente nel carrello;
 \item rimozione di un quantitativo di copie di un libro maggiore di quello presente nel carrello;
 \item aggiunta di un quantitativo di copie di un libro non disponibile in negozio;
 \item aggiunta e rimozione di copie di libri non presenti nel carrello;
 \item rimozione di tutte le copie di un libro dal carrello.
\end{itemize}

In tutte le operazioni si \`e verificato il corretto aggiornamento del numero di copie disponibili dei libri nel database del negozio.

\subsection{Test manuale tramite browser in locale}
Ogni volta che si terminava l'implementazione di una funzionalit\`a si \`e proceduti al test della stessa all'interno del container, come descritto nella sezione precedente. Conclusa questa fase con successo, mentre alcuni componenti del gruppo iniziavano ad implementare una nuova funzionalit\`a, un altro componente si occupava della realizzazione dell'interfaccia JSP relativa alla funzionalit\`a appena realizzata e testata. Terminata l'interfaccia, si \`e proceduti con un altro tipo di test, questa volta senza automatismi, attraverso il quale un componente del gruppo ha verificato l'interazione fra il sistema e l'interfaccia in questione. Il test \`e stato eseguito per tutte le funzionalit\`a realizzate e per tutte le prove la procedura \`e stata abbastanza simile:
\begin{itemize}
 \item Si eseguiva il test interno al container per avere a disposizione degli utenti gi\`a registrati, dei libri ed altri elementi, per evitarne la creazione a mano ad ogni prova;
 \item Un componente del gruppo accedeva tramite browser al sistema (in questo test il sistema \`e visibile ancora solo in locale);
 \item Venivano eseguite le operazioni (in modo corretto) che un utente avrebbe tentato per poter sfruttare la funzionalit\`a in questione;
 \item Si verificava la reazione del sistema ad operazioni collegate alla funzionalit\`a da testare ma eseguite in maniera scorretta, per esempio attraverso input errati, oppure cercando si saltare qualche passaggio obbligato, come l'autenticazione, per accedere al alcuni servizi...
 \item Si navigava il sito (ci\`o che al momento era disponibile) eseguendo alcune operazioni in maniera abbastanza casuale, saltando da una pagina all'altra, cercando di simulare il comportamento di un possibile futuro utente, verificando che non si creassero errori o malfunzionamenti. 
\end{itemize}

\subsection{Test del prodotto finito}
Una volta realizzate tutte le funzionalit\`a ed aver testato sia il funzionamento interno del sistema che l'interazione con le interfacce, si \`e passati all'ultimo tipo di testing effettuato: si \`e pubblicato su una macchina del laboratorio il prodotto ed ogni componente del gruppo accedeva al negozio di libri tramite browser, ma questa volta non in locale ma tramite internet. In questo test si sono ripetute all'incirca le operazioni svolte nell'ultima fase di testing descritta, ma con la differenza che in questo caso:
\begin{itemize}
 \item si accedeva al servizio tramite internet;
 \item si eseguivano accessi concorrenti al negozio di libri (alcuni test sono stati effettuati dai vari componenti del gruppo in contemporanea, da macchine diverse);
 \item tutti i servizi del sistema erano attivi, essendo giunti in questa fase con il prodotto finito
\end{itemize}
